<!DOCTYPE html>
<html lang="zh-CN">
<head>
  <meta charset="UTF-8">
<meta name="viewport" content="width=device-width">
<meta name="theme-color" content="#222"><meta name="generator" content="Hexo 6.3.0">

  <link rel="apple-touch-icon" sizes="180x180" href="/images/apple-touch-icon-next.png">
  <link rel="icon" type="image/png" sizes="32x32" href="/images/favicon-32x32-next.png">
  <link rel="icon" type="image/png" sizes="16x16" href="/images/favicon-16x16-next.png">
  <link rel="mask-icon" href="/images/logo.svg" color="#222">

<link rel="stylesheet" href="/css/main.css">



<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.4.0/css/all.min.css" integrity="sha256-HtsXJanqjKTc8vVQjO4YMhiqFoXkfBsjBWcX91T1jr8=" crossorigin="anonymous">
  <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/animate.css/3.1.1/animate.min.css" integrity="sha256-PR7ttpcvz8qrF57fur/yAx1qXMFJeJFiA6pSzWi0OIE=" crossorigin="anonymous">
  <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/pace/1.2.4/themes/blue/pace-theme-minimal.css">
  <script src="https://cdnjs.cloudflare.com/ajax/libs/pace/1.2.4/pace.min.js" integrity="sha256-gqd7YTjg/BtfqWSwsJOvndl0Bxc8gFImLEkXQT8+qj0=" crossorigin="anonymous"></script>

<script class="next-config" data-name="main" type="application/json">{"hostname":"example.com","root":"/","images":"/images","scheme":"Gemini","darkmode":false,"version":"8.17.1","exturl":false,"sidebar":{"position":"left","display":"post","padding":18,"offset":12},"copycode":{"enable":false,"style":null},"bookmark":{"enable":false,"color":"#222","save":"auto"},"mediumzoom":false,"lazyload":false,"pangu":false,"comments":{"style":"tabs","active":null,"storage":true,"lazyload":false,"nav":null},"stickytabs":false,"motion":{"enable":true,"async":false,"transition":{"menu_item":"fadeInDown","post_block":"fadeIn","post_header":"fadeInDown","post_body":"fadeInDown","coll_header":"fadeInLeft","sidebar":"fadeInUp"}},"prism":false,"i18n":{"placeholder":"搜索...","empty":"没有找到任何搜索结果：${query}","hits_time":"找到 ${hits} 个搜索结果（用时 ${time} 毫秒）","hits":"找到 ${hits} 个搜索结果"}}</script><script src="/js/config.js"></script>

    <meta name="description" content="随着互联网的发展，应用系统的流量不断扩大，进而导致系统架构也在不断演变，从互联网早期到现在大致可以分为如下两阶段的变化：  单体应用架构（Monolithic Architecture） 整个系统所有功能部署到同一个进程中。（代码打包成一个文件或者多个文件）。   分布式架构（Distributed Architecture） 整个系统的功能单元分散到不同进程中，可能在同一台服务器的不同进程，也可">
<meta property="og:type" content="article">
<meta property="og:title" content="一文读懂：系统架构发展历程">
<meta property="og:url" content="http://example.com/2021/05/03/%E4%B8%80%E6%96%87%E8%AF%BB%E6%87%82%EF%BC%9A%E7%B3%BB%E7%BB%9F%E6%9E%B6%E6%9E%84%E5%8F%91%E5%B1%95%E5%8E%86%E7%A8%8B/index.html">
<meta property="og:site_name" content="幸福的小羊">
<meta property="og:description" content="随着互联网的发展，应用系统的流量不断扩大，进而导致系统架构也在不断演变，从互联网早期到现在大致可以分为如下两阶段的变化：  单体应用架构（Monolithic Architecture） 整个系统所有功能部署到同一个进程中。（代码打包成一个文件或者多个文件）。   分布式架构（Distributed Architecture） 整个系统的功能单元分散到不同进程中，可能在同一台服务器的不同进程，也可">
<meta property="og:locale" content="zh_CN">
<meta property="og:image" content="https://gitee.com/zhaowg3/images/raw/blog/202307141914615.png">
<meta property="og:image" content="https://gitee.com/zhaowg3/images/raw/blog/202307141915032.png">
<meta property="og:image" content="https://gitee.com/zhaowg3/images/raw/blog/202307141916510.png">
<meta property="og:image" content="https://gitee.com/zhaowg3/images/raw/blog/202307141916699.png">
<meta property="og:image" content="https://gitee.com/zhaowg3/images/raw/blog/202307141917419.png">
<meta property="og:image" content="https://gitee.com/zhaowg3/images/raw/blog/202307141917770.png">
<meta property="og:image" content="https://gitee.com/zhaowg3/images/raw/blog/202307141918277.png">
<meta property="og:image" content="https://gitee.com/zhaowg3/images/raw/blog/202307141918065.png">
<meta property="og:image" content="https://gitee.com/zhaowg3/images/raw/blog/202307141925817.png">
<meta property="og:image" content="https://gitee.com/zhaowg3/images/raw/blog/202307141919875.png">
<meta property="og:image" content="https://gitee.com/zhaowg3/images/raw/blog/202307141919939.png">
<meta property="og:image" content="https://gitee.com/zhaowg3/images/raw/blog/202307141920712.png">
<meta property="og:image" content="https://gitee.com/zhaowg3/images/raw/blog/202307141920198.png">
<meta property="og:image" content="https://gitee.com/zhaowg3/images/raw/blog/202307141921850.png">
<meta property="og:image" content="https://gitee.com/zhaowg3/images/raw/blog/202307141926255.png">
<meta property="og:image" content="https://gitee.com/zhaowg3/images/raw/blog/202307141926518.png">
<meta property="og:image" content="https://gitee.com/zhaowg3/images/raw/blog/202307141927406.png">
<meta property="og:image" content="https://gitee.com/zhaowg3/images/raw/blog/202307141927122.png">
<meta property="og:image" content="https://gitee.com/zhaowg3/images/raw/blog/202307141928231.png">
<meta property="og:image" content="https://gitee.com/zhaowg3/images/raw/blog/202307141928961.png">
<meta property="og:image" content="https://gitee.com/zhaowg3/images/raw/blog/202307141929615.png">
<meta property="og:image" content="https://gitee.com/zhaowg3/images/raw/blog/202307141929188.png">
<meta property="og:image" content="https://gitee.com/zhaowg3/images/raw/blog/202307141930973.png">
<meta property="og:image" content="https://gitee.com/zhaowg3/images/raw/blog/202307141930487.png">
<meta property="og:image" content="https://gitee.com/zhaowg3/images/raw/blog/202307141931866.png">
<meta property="og:image" content="https://gitee.com/zhaowg3/images/raw/blog/202307141931326.png">
<meta property="og:image" content="https://gitee.com/zhaowg3/images/raw/blog/202307141931093.png">
<meta property="og:image" content="https://gitee.com/zhaowg3/images/raw/blog/202307141932256.png">
<meta property="article:published_time" content="2021-05-03T04:00:00.000Z">
<meta property="article:modified_time" content="2023-07-01T02:46:25.000Z">
<meta property="article:author" content="zhaowg">
<meta property="article:tag" content="Spring">
<meta property="article:tag" content="Spring Cloud">
<meta name="twitter:card" content="summary">
<meta name="twitter:image" content="https://gitee.com/zhaowg3/images/raw/blog/202307141914615.png">


<link rel="canonical" href="http://example.com/2021/05/03/%E4%B8%80%E6%96%87%E8%AF%BB%E6%87%82%EF%BC%9A%E7%B3%BB%E7%BB%9F%E6%9E%B6%E6%9E%84%E5%8F%91%E5%B1%95%E5%8E%86%E7%A8%8B/">



<script class="next-config" data-name="page" type="application/json">{"sidebar":"","isHome":false,"isPost":true,"lang":"zh-CN","comments":true,"permalink":"http://example.com/2021/05/03/%E4%B8%80%E6%96%87%E8%AF%BB%E6%87%82%EF%BC%9A%E7%B3%BB%E7%BB%9F%E6%9E%B6%E6%9E%84%E5%8F%91%E5%B1%95%E5%8E%86%E7%A8%8B/","path":"2021/05/03/一文读懂：系统架构发展历程/","title":"一文读懂：系统架构发展历程"}</script>

<script class="next-config" data-name="calendar" type="application/json">""</script>
<title>一文读懂：系统架构发展历程 | 幸福的小羊</title>
  








  <noscript>
    <link rel="stylesheet" href="/css/noscript.css">
  </noscript>
</head>

<body itemscope itemtype="http://schema.org/WebPage" class="use-motion">
  <div class="headband"></div>

  <main class="main">
    <div class="column">
      <header class="header" itemscope itemtype="http://schema.org/WPHeader"><div class="site-brand-container">
  <div class="site-nav-toggle">
    <div class="toggle" aria-label="切换导航栏" role="button">
        <span class="toggle-line"></span>
        <span class="toggle-line"></span>
        <span class="toggle-line"></span>
    </div>
  </div>

  <div class="site-meta">

    <a href="/" class="brand" rel="start">
      <i class="logo-line"></i>
      <p class="site-title">幸福的小羊</p>
      <i class="logo-line"></i>
    </a>
      <p class="site-subtitle" itemprop="description">蓝天，白云，青草地</p>
  </div>

  <div class="site-nav-right">
    <div class="toggle popup-trigger" aria-label="搜索" role="button">
    </div>
  </div>
</div>



<nav class="site-nav">
  <ul class="main-menu menu"><li class="menu-item menu-item-home"><a href="/" rel="section"><i class="fa fa-home fa-fw"></i>首页</a></li><li class="menu-item menu-item-about"><a href="/about/" rel="section"><i class="fa fa-user fa-fw"></i>关于</a></li><li class="menu-item menu-item-categories"><a href="/categories/" rel="section"><i class="fa fa-th fa-fw"></i>分类<span class="badge">2</span></a></li><li class="menu-item menu-item-archives"><a href="/archives/" rel="section"><i class="fa fa-archive fa-fw"></i>归档<span class="badge">3</span></a></li>
  </ul>
</nav>




</header>
        
  
  <aside class="sidebar">

    <div class="sidebar-inner sidebar-nav-active sidebar-toc-active">
      <ul class="sidebar-nav">
        <li class="sidebar-nav-toc">
          文章目录
        </li>
        <li class="sidebar-nav-overview">
          站点概览
        </li>
      </ul>

      <div class="sidebar-panel-container">
        <!--noindex-->
        <div class="post-toc-wrap sidebar-panel">
            <div class="post-toc animated"><ol class="nav"><li class="nav-item nav-level-1"><a class="nav-link" href="#%E5%8D%95%E4%BD%93%E5%BA%94%E7%94%A8%E6%9E%B6%E6%9E%84"><span class="nav-number">1.</span> <span class="nav-text">单体应用架构</span></a><ol class="nav-child"><li class="nav-item nav-level-2"><a class="nav-link" href="#%E7%AE%80%E5%8D%95%E5%8D%95%E4%BD%93%E6%A8%A1%E5%BC%8F"><span class="nav-number">1.1.</span> <span class="nav-text">简单单体模式</span></a></li><li class="nav-item nav-level-2"><a class="nav-link" href="#MVC%E6%A8%A1%E5%BC%8F"><span class="nav-number">1.2.</span> <span class="nav-text">MVC模式</span></a></li><li class="nav-item nav-level-2"><a class="nav-link" href="#%E5%89%8D%E5%90%8E%E7%AB%AF%E5%88%86%E7%A6%BB"><span class="nav-number">1.3.</span> <span class="nav-text">前后端分离</span></a></li><li class="nav-item nav-level-2"><a class="nav-link" href="#%E7%BB%84%E4%BB%B6%E6%A8%A1%E5%BC%8F"><span class="nav-number">1.4.</span> <span class="nav-text">组件模式</span></a></li><li class="nav-item nav-level-2"><a class="nav-link" href="#%E7%B1%BB%E5%BA%93%E6%A8%A1%E5%BC%8F"><span class="nav-number">1.5.</span> <span class="nav-text">类库模式</span></a></li><li class="nav-item nav-level-2"><a class="nav-link" href="#%E5%8D%95%E4%BD%93%E5%BA%94%E7%94%A8%E6%9E%B6%E6%9E%84%E6%BC%94%E5%8F%98"><span class="nav-number">1.6.</span> <span class="nav-text">单体应用架构演变</span></a></li><li class="nav-item nav-level-2"><a class="nav-link" href="#%E4%BC%98%E7%82%B9"><span class="nav-number">1.7.</span> <span class="nav-text">优点</span></a></li><li class="nav-item nav-level-2"><a class="nav-link" href="#%E7%BC%BA%E7%82%B9"><span class="nav-number">1.8.</span> <span class="nav-text">缺点</span></a></li></ol></li><li class="nav-item nav-level-1"><a class="nav-link" href="#%E5%9E%82%E7%9B%B4%E5%BA%94%E7%94%A8%E6%9E%B6%E6%9E%84"><span class="nav-number">2.</span> <span class="nav-text">垂直应用架构</span></a><ol class="nav-child"><li class="nav-item nav-level-2"><a class="nav-link" href="#%E4%BC%98%E7%82%B9-1"><span class="nav-number">2.1.</span> <span class="nav-text">优点</span></a></li><li class="nav-item nav-level-2"><a class="nav-link" href="#%E7%BC%BA%E7%82%B9-1"><span class="nav-number">2.2.</span> <span class="nav-text">缺点</span></a></li></ol></li><li class="nav-item nav-level-1"><a class="nav-link" href="#%E5%88%86%E5%B8%83%E5%BC%8F%E6%9E%B6%E6%9E%84"><span class="nav-number">3.</span> <span class="nav-text">分布式架构</span></a><ol class="nav-child"><li class="nav-item nav-level-2"><a class="nav-link" href="#SOA%E6%9E%B6%E6%9E%84"><span class="nav-number">3.1.</span> <span class="nav-text">SOA架构</span></a><ol class="nav-child"><li class="nav-item nav-level-3"><a class="nav-link" href="#%E9%9B%86%E4%B8%AD%E5%BC%8F%E7%AE%A1%E7%90%86"><span class="nav-number">3.1.1.</span> <span class="nav-text">集中式管理</span></a><ol class="nav-child"><li class="nav-item nav-level-4"><a class="nav-link" href="#%E9%80%82%E7%94%A8%E5%9C%BA%E6%99%AF"><span class="nav-number">3.1.1.1.</span> <span class="nav-text">适用场景</span></a></li><li class="nav-item nav-level-4"><a class="nav-link" href="#%E4%BB%80%E4%B9%88%E6%98%AFESB%EF%BC%9F"><span class="nav-number">3.1.1.2.</span> <span class="nav-text">什么是ESB？</span></a></li><li class="nav-item nav-level-4"><a class="nav-link" href="#ESB%E5%8A%9F%E8%83%BD%E5%AE%9A%E4%BD%8D"><span class="nav-number">3.1.1.3.</span> <span class="nav-text">ESB功能定位</span></a></li><li class="nav-item nav-level-4"><a class="nav-link" href="#%E4%BC%98%E7%82%B9-2"><span class="nav-number">3.1.1.4.</span> <span class="nav-text">优点</span></a></li><li class="nav-item nav-level-4"><a class="nav-link" href="#%E7%BC%BA%E7%82%B9-2"><span class="nav-number">3.1.1.5.</span> <span class="nav-text">缺点</span></a></li></ol></li><li class="nav-item nav-level-3"><a class="nav-link" href="#%E5%88%86%E5%B8%83%E5%BC%8F%E6%9C%8D%E5%8A%A1%E5%8C%96"><span class="nav-number">3.1.2.</span> <span class="nav-text">分布式服务化</span></a><ol class="nav-child"><li class="nav-item nav-level-4"><a class="nav-link" href="#%E9%80%82%E7%94%A8%E5%9C%BA%E6%99%AF-1"><span class="nav-number">3.1.2.1.</span> <span class="nav-text">适用场景</span></a></li><li class="nav-item nav-level-4"><a class="nav-link" href="#%E4%BC%98%E7%82%B9-3"><span class="nav-number">3.1.2.2.</span> <span class="nav-text">优点</span></a></li><li class="nav-item nav-level-4"><a class="nav-link" href="#%E7%BC%BA%E7%82%B9-3"><span class="nav-number">3.1.2.3.</span> <span class="nav-text">缺点</span></a></li></ol></li></ol></li><li class="nav-item nav-level-2"><a class="nav-link" href="#%E5%BE%AE%E6%9C%8D%E5%8A%A1%E6%9E%B6%E6%9E%84"><span class="nav-number">3.2.</span> <span class="nav-text">微服务架构</span></a><ol class="nav-child"><li class="nav-item nav-level-3"><a class="nav-link" href="#%E4%BB%80%E4%B9%88%E6%98%AF%E5%BE%AE%E6%9C%8D%E5%8A%A1%EF%BC%9F"><span class="nav-number">3.2.1.</span> <span class="nav-text">什么是微服务？</span></a></li><li class="nav-item nav-level-3"><a class="nav-link" href="#%E5%BE%AE%E6%9C%8D%E5%8A%A1%E4%B8%8ESOA%E5%8C%BA%E5%88%AB"><span class="nav-number">3.2.2.</span> <span class="nav-text">微服务与SOA区别</span></a></li><li class="nav-item nav-level-3"><a class="nav-link" href="#%E5%BE%AE%E6%9C%8D%E5%8A%A1%E7%9A%84%E7%89%B9%E7%82%B9"><span class="nav-number">3.2.3.</span> <span class="nav-text">微服务的特点</span></a></li><li class="nav-item nav-level-3"><a class="nav-link" href="#%E4%BC%98%E7%82%B9-4"><span class="nav-number">3.2.4.</span> <span class="nav-text">优点</span></a></li><li class="nav-item nav-level-3"><a class="nav-link" href="#%E7%BC%BA%E7%82%B9-4"><span class="nav-number">3.2.5.</span> <span class="nav-text">缺点</span></a></li><li class="nav-item nav-level-3"><a class="nav-link" href="#%E5%B8%B8%E8%A7%81%E9%97%AE%E9%A2%98"><span class="nav-number">3.2.6.</span> <span class="nav-text">常见问题</span></a></li><li class="nav-item nav-level-3"><a class="nav-link" href="#%E5%B8%B8%E8%A7%81%E6%A6%82%E5%BF%B5"><span class="nav-number">3.2.7.</span> <span class="nav-text">常见概念</span></a><ol class="nav-child"><li class="nav-item nav-level-4"><a class="nav-link" href="#%E5%88%86%E5%B8%83%E5%BC%8F%E9%85%8D%E7%BD%AE%E4%B8%AD%E5%BF%83"><span class="nav-number">3.2.7.1.</span> <span class="nav-text">分布式配置中心</span></a></li><li class="nav-item nav-level-4"><a class="nav-link" href="#%E6%9C%8D%E5%8A%A1%E6%B3%A8%E5%86%8C%E5%8F%91%E7%8E%B0%E4%B8%AD%E5%BF%83"><span class="nav-number">3.2.7.2.</span> <span class="nav-text">服务注册发现中心</span></a></li><li class="nav-item nav-level-4"><a class="nav-link" href="#%E6%9C%8D%E5%8A%A1%E8%B0%83%E7%94%A8"><span class="nav-number">3.2.7.3.</span> <span class="nav-text">服务调用</span></a></li><li class="nav-item nav-level-4"><a class="nav-link" href="#%E5%88%86%E5%B8%83%E5%BC%8F%E6%B6%88%E6%81%AF"><span class="nav-number">3.2.7.4.</span> <span class="nav-text">分布式消息</span></a></li><li class="nav-item nav-level-4"><a class="nav-link" href="#%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1"><span class="nav-number">3.2.7.5.</span> <span class="nav-text">负载均衡</span></a></li><li class="nav-item nav-level-4"><a class="nav-link" href="#%E6%9C%8D%E5%8A%A1%E7%86%94%E6%96%AD-%E6%9C%8D%E5%8A%A1%E9%99%8D%E7%BA%A7"><span class="nav-number">3.2.7.6.</span> <span class="nav-text">服务熔断&#x2F;服务降级</span></a></li><li class="nav-item nav-level-4"><a class="nav-link" href="#%E5%88%86%E5%B8%83%E5%BC%8F%E9%93%BE%E8%B7%AF%E8%BF%BD%E8%B8%AA"><span class="nav-number">3.2.7.7.</span> <span class="nav-text">分布式链路追踪</span></a></li><li class="nav-item nav-level-4"><a class="nav-link" href="#%E7%BD%91%E5%85%B3%E8%B7%AF%E7%94%B1"><span class="nav-number">3.2.7.8.</span> <span class="nav-text">网关路由</span></a></li></ol></li><li class="nav-item nav-level-3"><a class="nav-link" href="#%E5%BE%AE%E6%9C%8D%E5%8A%A1%E6%9E%B6%E6%9E%84%E7%9A%84%E5%B8%B8%E8%A7%81%E8%A7%A3%E5%86%B3%E6%96%B9%E6%A1%88"><span class="nav-number">3.2.8.</span> <span class="nav-text">微服务架构的常见解决方案</span></a></li></ol></li><li class="nav-item nav-level-2"><a class="nav-link" href="#%E6%9C%8D%E5%8A%A1%E7%BD%91%E6%A0%BC"><span class="nav-number">3.3.</span> <span class="nav-text">服务网格</span></a><ol class="nav-child"><li class="nav-item nav-level-3"><a class="nav-link" href="#%E4%BB%80%E4%B9%88%E6%98%AF%E6%9C%8D%E5%8A%A1%E7%BD%91%E6%A0%BC%EF%BC%9F"><span class="nav-number">3.3.1.</span> <span class="nav-text">什么是服务网格？</span></a></li><li class="nav-item nav-level-3"><a class="nav-link" href="#%E6%9C%8D%E5%8A%A1%E7%BD%91%E6%A0%BC%E7%9A%84%E7%89%B9%E7%82%B9"><span class="nav-number">3.3.2.</span> <span class="nav-text">服务网格的特点</span></a></li><li class="nav-item nav-level-3"><a class="nav-link" href="#%E6%9C%8D%E5%8A%A1%E7%BD%91%E6%A0%BC%E7%9A%84%E9%80%82%E7%94%A8%E5%9C%BA%E6%99%AF%EF%BC%9F"><span class="nav-number">3.3.3.</span> <span class="nav-text">服务网格的适用场景？</span></a></li></ol></li><li class="nav-item nav-level-2"><a class="nav-link" href="#%E5%88%86%E5%B8%83%E5%BC%8F%E6%9E%B6%E6%9E%84%E6%BC%94%E5%8F%98"><span class="nav-number">3.4.</span> <span class="nav-text">分布式架构演变</span></a></li></ol></li><li class="nav-item nav-level-1"><a class="nav-link" href="#%E5%8F%82%E8%80%83%E8%B5%84%E6%96%99"><span class="nav-number">4.</span> <span class="nav-text">参考资料</span></a></li></ol></div>
        </div>
        <!--/noindex-->

        <div class="site-overview-wrap sidebar-panel">
          <div class="site-author animated" itemprop="author" itemscope itemtype="http://schema.org/Person">
    <img class="site-author-image" itemprop="image" alt="zhaowg"
      src="/images/sheep.jpg">
  <p class="site-author-name" itemprop="name">zhaowg</p>
  <div class="site-description" itemprop="description">个人博客，分享技术和日常生活</div>
</div>
<div class="site-state-wrap animated">
  <nav class="site-state">
      <div class="site-state-item site-state-posts">
        <a href="/archives/">
          <span class="site-state-item-count">3</span>
          <span class="site-state-item-name">日志</span>
        </a>
      </div>
      <div class="site-state-item site-state-categories">
          <a href="/categories/">
        <span class="site-state-item-count">2</span>
        <span class="site-state-item-name">分类</span></a>
      </div>
      <div class="site-state-item site-state-tags">
          <a href="/tags/">
        <span class="site-state-item-count">2</span>
        <span class="site-state-item-name">标签</span></a>
      </div>
  </nav>
</div>

        </div>
      </div>
        <div class="back-to-top animated" role="button" aria-label="返回顶部">
          <i class="fa fa-arrow-up"></i>
          <span>0%</span>
        </div>
    </div>

    
  </aside>


    </div>

    <div class="main-inner post posts-expand">


  


<div class="post-block">
  
  

  <article itemscope itemtype="http://schema.org/Article" class="post-content" lang="zh-CN">
    <link itemprop="mainEntityOfPage" href="http://example.com/2021/05/03/%E4%B8%80%E6%96%87%E8%AF%BB%E6%87%82%EF%BC%9A%E7%B3%BB%E7%BB%9F%E6%9E%B6%E6%9E%84%E5%8F%91%E5%B1%95%E5%8E%86%E7%A8%8B/">

    <span hidden itemprop="author" itemscope itemtype="http://schema.org/Person">
      <meta itemprop="image" content="/images/sheep.jpg">
      <meta itemprop="name" content="zhaowg">
    </span>

    <span hidden itemprop="publisher" itemscope itemtype="http://schema.org/Organization">
      <meta itemprop="name" content="幸福的小羊">
      <meta itemprop="description" content="个人博客，分享技术和日常生活">
    </span>

    <span hidden itemprop="post" itemscope itemtype="http://schema.org/CreativeWork">
      <meta itemprop="name" content="一文读懂：系统架构发展历程 | 幸福的小羊">
      <meta itemprop="description" content="">
    </span>
      <header class="post-header">
        <h1 class="post-title" itemprop="name headline">
          一文读懂：系统架构发展历程
        </h1>

        <div class="post-meta-container">
          <div class="post-meta">
    <span class="post-meta-item">
      <span class="post-meta-item-icon">
        <i class="far fa-calendar"></i>
      </span>
      <span class="post-meta-item-text">发表于</span>

      <time title="创建时间：2021-05-03 12:00:00" itemprop="dateCreated datePublished" datetime="2021-05-03T12:00:00+08:00">2021-05-03</time>
    </span>
    <span class="post-meta-item">
      <span class="post-meta-item-icon">
        <i class="far fa-calendar-check"></i>
      </span>
      <span class="post-meta-item-text">更新于</span>
      <time title="修改时间：2023-07-01 10:46:25" itemprop="dateModified" datetime="2023-07-01T10:46:25+08:00">2023-07-01</time>
    </span>
    <span class="post-meta-item">
      <span class="post-meta-item-icon">
        <i class="far fa-folder"></i>
      </span>
      <span class="post-meta-item-text">分类于</span>
        <span itemprop="about" itemscope itemtype="http://schema.org/Thing">
          <a href="/categories/Spring-Cloud/" itemprop="url" rel="index"><span itemprop="name">Spring Cloud</span></a>
        </span>
    </span>

  
</div>

        </div>
      </header>

    
    
    
    <div class="post-body" itemprop="articleBody"><p>随着互联网的发展，应用系统的流量不断扩大，进而导致系统架构也在不断演变，从互联网早期到现在大致可以分为如下两阶段的变化：<br><img src="https://gitee.com/zhaowg3/images/raw/blog/202307141914615.png"></p>
<ul>
<li><strong>单体应用架构（Monolithic Architecture）</strong><ul>
<li>整个系统所有功能部署到同一个进程中。（代码打包成一个文件或者多个文件）。</li>
</ul>
</li>
<li><strong>分布式架构（Distributed Architecture）</strong><ul>
<li>整个系统的功能单元分散到不同进程中，可能在同一台服务器的不同进程，也可能在不同的服务器上，然后由多个进程共同提供业务能力<span id="more"></span></li>
</ul>
</li>
</ul>
<h1 id="单体应用架构"><a href="#单体应用架构" class="headerlink" title="单体应用架构"></a>单体应用架构</h1><p><strong>背景：</strong><br>互联网早期，功能比较简单，网站的访问量也小，所以这时一般只需要一个应用程序，里面包含了所有业务的代码。部署的时候也是只有一个war包，部署到一台服务器的tomcat上即可。<br>此时的调用关系如下：<br><img src="https://gitee.com/zhaowg3/images/raw/blog/202307141915032.png"></p>
<h2 id="简单单体模式"><a href="#简单单体模式" class="headerlink" title="简单单体模式"></a>简单单体模式</h2><p>早期的单体应用架构，也叫简单单体架构模式，代码之间没有分层，调用关系混乱。一般只有个别开发者能全部理解整个逻辑，在初期，业务功能简单的情况下，这种模式可以使团队成员快速上手。<br><img src="https://gitee.com/zhaowg3/images/raw/blog/202307141916510.png"></p>
<h2 id="MVC模式"><a href="#MVC模式" class="headerlink" title="MVC模式"></a>MVC模式</h2><p>随着公司业务的发展，越来越多的功能需要开发，因此也有越来越多的研发人员加入进来，如果继续使用单体应用架构模式，由于代码层面没有分层，调用关系混乱，随着功能的增加，调用关系会更加复杂，后续维护会变得更加困难，修改某一处代码，可能导致其他功能不可用；一个项目中，了解整个逻辑的也可能只有少数人。<br>基于如上确定，出现了MVC模式，将代码划分为三个层面：</p>
<ul>
<li>Model-模型层：代表业务数据实体部分，负责和数据库交互</li>
<li>View-视图层：代表前端的展示部分</li>
<li>Controller-控制层&#x2F;逻辑处理层：代表请求分发，处理调度部分</li>
</ul>
<p>每一层专注于自己负责的领域，例如Controller层主要负责业务的逻辑功能实现，Model层则主要是负责与数据库实体的交互，后来出现的hibernate，mybatis等ORM技术框架都是基于这一层的扩展，view层则负责对前端界面的渲染，各层之间调用关系清晰，基于此三层模式，研发团队也可以基于此进行划分，职责清晰。<br><img src="https://gitee.com/zhaowg3/images/raw/blog/202307141916699.png"></p>
<h2 id="前后端分离"><a href="#前后端分离" class="headerlink" title="前后端分离"></a>前后端分离</h2><p>经过上面MVC模式对代码的分层，调用关系已经变得比较清晰了，但是此时的视图展示主要还是通过JSP或页面标签Tag技术、后端FreeMaker或Velocity等，导致HTML&#x2F;CSS&#x2F;JS等前端技术与后端逻辑处理耦合在一起。<br>此后，随着Ajax、JQuery等技术的兴起，以及前端UI组件技术的大行其道，越来越多有关界面的展示逻辑被移到浏览器客户端来处理。此时演化出来一种新模式：</p>
<ul>
<li>将和前端界面展示相关的内容拆分出来，前端关注页面的样式与动态数据的解析以及渲染。</li>
<li>后端专注于具体业务逻辑，提供基于URL的接口，返回JSON格式的数据即可。不再渲染页面，不再控制前端效果。<br><img src="https://gitee.com/zhaowg3/images/raw/blog/202307141917419.png"></li>
</ul>
<p>由于前后端分离（水平拆分）的出现，进一步影响了研发团队的组成，分为了前端开发团队和后端开发团队，前端团队负责前端系统开发；后端团队负责后端系统开发，双方一起定制前后端系统的数据接口即可。只要接口保持不变，那么前后端系统可以各自独立发展和维护。</p>
<h2 id="组件模式"><a href="#组件模式" class="headerlink" title="组件模式"></a>组件模式</h2><p>随着公司进一步发展，又有很多新系统需要开发，如果还在一个项目中继续开发，虽然MVC已经对代码层面进行了分层，但是没有分离各系统，所有系统的代码都在同一个项目中，会有如下缺点：</p>
<ul>
<li>代码管理混乱。任何一个人都可以修改项目中的任意代码，是很不安全的。应该根据每个研发人员负责的系统开放对应的项目权限，做到对代码的保护。</li>
<li>影响开发效率。如果设计的系统过多，项目过大，例如超过100万行，研发人员单就在本地打开项目，编译项目都会耗时很久。</li>
</ul>
<p>基于以上问题，可以将项目中的每个模块拆分成一个子项目，每个模块独立编译打包成一个组件，然后所有需要的组件一起部署到一个容器里。这样研发只需要关注自己对应模块的项目即可，这就是组件模式。<br>组件模式的出现主要是在代码结构层面的更改，使得结构更加清晰，职责也更加明确，开发团队可以根据自身负责的模块拆分成多个子项目，每个团队只需操作自己负责的项目即可。<br><img src="https://gitee.com/zhaowg3/images/raw/blog/202307141917770.png"></p>
<h2 id="类库模式"><a href="#类库模式" class="headerlink" title="类库模式"></a>类库模式</h2><p>基于组件模式的基础上，如果模块1需要复用模块2中的某些功能，这时可以直接将B系统的某些组件作为依赖库，打包到A系统来使用。<br><img src="https://gitee.com/zhaowg3/images/raw/blog/202307141918277.png"></p>
<h2 id="单体应用架构演变"><a href="#单体应用架构演变" class="headerlink" title="单体应用架构演变"></a>单体应用架构演变</h2><p>经过上面的介绍，单体应用架构其实也发生了响应的演化，此阶段的演化更多的是侧重开发人员的职责划分，代码的规范性和可重用性等。<br><img src="https://gitee.com/zhaowg3/images/raw/blog/202307141918065.png"></p>
<h2 id="优点"><a href="#优点" class="headerlink" title="优点"></a>优点</h2><p>在前期功能简单，流量较小时，有如下优点：</p>
<ul>
<li>项目架构简单，适合小型项目，开发成本低。</li>
<li>部署简单，项目只有一个包，且只需部署一个节点。</li>
</ul>
<h2 id="缺点"><a href="#缺点" class="headerlink" title="缺点"></a>缺点</h2><p>随着系统功能增多，流量扩大，代码量也在不断增多，这个时候就暴露了单体架构的如下缺点：</p>
<ul>
<li>团队协作效率变差，公共功能重复开发，且多人开发同一个项目，容易产生冲突。</li>
<li>可用性差。虽然部署方式简单，但是对系统的可用性影响很大。每次有任何新功能变更，都需要对整个系统重新发布，进而导致发布期间系统不可用。并且随着系统越来越庞大，部署时长和风险也越来越高。</li>
<li>扩展性差。主业务和次业务都耦合在一起，横向扩展复杂。系统性能扩展只能通过扩展集群结点，成本高。</li>
</ul>
<h1 id="垂直应用架构"><a href="#垂直应用架构" class="headerlink" title="垂直应用架构"></a>垂直应用架构</h1><p>虽然单体应用架构的组件模式，已经按照业务将之前的大项目拆分为了不同的子项目，但是打包部署还是集中到了一个项目，任何一个子项目的功能变更，都需要重新发布整个项目，导致整个项目在发布阶段不可用，随着子项目的增多，重新发布变得越来越慢。<br>在扩展性方面，无法单独增对某个子项目进行扩展，只能对整个项目扩展，这也造成了资源的浪费，例如子项目A流量大，使用人数多，可以增加多个节点进行部署，子项目B使用人数少，只需要一个节点即可，而单体应用架构是无法做到这一点。<br>在性能提升方面，和扩展性一样，无法针对某个子项目单独调整性能，例如子项目C是CPU消耗性，可以将其部署中多核服务器中，而子项目D是内存消耗性，可以针对其提高服务器内存，在单体应用架构中也是无法做到的，只能针对整个项目做提升。<br>为了解决上述问题，在分布式架构之前，也出现了另一种架构方式，即将原来的一个大项目，按照业务场景拆分为互不相干的单体架构的项目（垂直拆分），各个项目之间没有任何交互，做到独立发布，互不影响。<br><img src="https://gitee.com/zhaowg3/images/raw/blog/202307141925817.png"></p>
<h2 id="优点-1"><a href="#优点-1" class="headerlink" title="优点"></a>优点</h2><p>和单体应用架构相比，有如下优点</p>
<ol>
<li>发布时影响范围可控。例如本次修改了应用系统A的功能，只需要重新发布系统A即可，不影响其他系统的正常使用。</li>
<li>性能优化方面，可以针对每个应用做不同的性能优化。</li>
<li>扩展性方面，可以针对不同应用做不同的扩展。</li>
<li>分工进一步明确。基于业务拆分成多个应用，研发团队也可以拆分成多个小组，每个小组职责清晰。</li>
</ol>
<h2 id="缺点-1"><a href="#缺点-1" class="headerlink" title="缺点"></a>缺点</h2><ul>
<li>由于各业务系统相互独立，系统之间没有交互，形成了信息孤岛，导致数据无法互通，逻辑无法共用。</li>
<li>由于系统无法互相调用,所以会造成代码冗余,由于项目越来越大,冗余代码可能会越来越多,造成系统性能降低</li>
</ul>
<h1 id="分布式架构"><a href="#分布式架构" class="headerlink" title="分布式架构"></a>分布式架构</h1><p>互联网发展到当下，各个系统之间不再可能相互独立，所以必须打破各系统之间的信息壁垒，保持数据互通，逻辑共用。此时，各系统可以将各自的功能开放出来，彼此之间通过各种通信协议进行交互，这样既可以避免信息孤岛，也减少了重复代码，A系统使用B系统某些功能时，直接调用B系统开放出来的服务接口即可。<br><img src="https://gitee.com/zhaowg3/images/raw/blog/202307141919875.png"><br>此时，由于各个业务应用系统可以单独部署，且可以部署在不同机器上，每个业务只负责自己的功能，彼此之间通过各种通信协议进行信息交互，所以这类架构统称为分布式架构。<br>通过分布式架构，可以解决前面介绍单体架构提到的 项目不断变庞大时产生的各种不利于系统长期稳定发展的问题，包括代码质量、开发效率、系统可靠性和扩展性等，但是分布式在解决单体架构中的问题的同时，也引进了其他问题，比如：</p>
<ul>
<li>系统间耦合度变高，调用关系错综复杂，难以维护。</li>
<li>在分布式架构下，当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心对集群进行实时管理。</li>
</ul>
<h2 id="SOA架构"><a href="#SOA架构" class="headerlink" title="SOA架构"></a>SOA架构</h2><p>为了解决各系统间形成的信息孤岛，提出了将各个系统的功能开放出来，各系统之间通过多种通信协议互相调用。基于此出现了SOA架构，顾名词语就是面向服务架构：Service Oriented Architecture。关注点是服务（业务最基本的功能单元），将各个系统的不同功能单元抽象为服务，实现不同模块的解耦，服务间彼此通过标准的接口协议连接起来，从而实现各异构系统间的服务调用、消息交换和资源共享，并以此完成特定功能的实现。<br>相比较之前的垂直架构，拆分的力度更细，垂直架构是按照业务进行拆分，而SOA则是在业务拆分之后进一步按照功能单元进行拆分，这样拆分之后，功能与具体所属的应用进行了解耦，可以复用到任何地方。</p>
<ul>
<li>从宏观视角来看，SOA强调整个企业IT生态环境是一个整体，之前各个孤立的系统，被拆分为不同粒度的服务，而服务又可以组装到更大的业务系统中，不同来源的服务通过编排到同一个流程中，可以形成更加强大的功能，处理更加复杂的业务场景。</li>
<li>从研发视角看，系统的复用性从之前代码级别，扩展到了业务服务级别；能够快速应对业务需求和集成需求的变更。<br><img src="https://gitee.com/zhaowg3/images/raw/blog/202307141919939.png"><br>以一个简单例子描述下，比如发送短信功能，可能在各个业务系统都需要发送短信，之前需要在每个业务系统中都写一遍发送短信，而现在只需要将发送短信功能提取成一个服务并对外开放，每个系统在使用的时候只需要调用发送短信服务即可，不再需要重复编写。<br>演化到现在，虽然抽离出来了服务，系统之间也可以通过通信协议相互调用，实现了服务的复用性，但是随着服务越来越多，系统间的调用关系变得越来越复杂，耦合度也越来越高，难以管理。其次，每个服务都是一个集群，在实际调用的时候，如何找到服务，如何选择服务，以及当某个节点下线后，如何及时通知调用方等等一系列关于服务治理方面的问题也急需解决。<br>在实际落地中，跟企业 IT 特点、服务能力和发展阶段直接相关。目前常见的落地方式主要有集中式管理和分布式服务化两种：</li>
</ul>
<h3 id="集中式管理"><a href="#集中式管理" class="headerlink" title="集中式管理"></a>集中式管理</h3><h4 id="适用场景"><a href="#适用场景" class="headerlink" title="适用场景"></a>适用场景</h4><p>主要是集成，特别是对无法改变的异构系统做适配整合，比如遗留系统，外部系统等。<br>传统企业的IT内部遗留系统包袱较重，资源整合很大一部分是需要打通新旧技术体系的任督二脉，所以更偏重于以 ESB 作为基础支撑技术，以整合集成为核心，将各个新旧系统的业务能力逐渐的在 ESB 容器上聚合和集成起来。</p>
<h4 id="什么是ESB？"><a href="#什么是ESB？" class="headerlink" title="什么是ESB？"></a>什么是ESB？</h4><p>ESB 就是采用了 “总线” 的模式来管理和简化应用之间的集成拓扑结构，是一种在松散耦合的服务和应用之间标准的集成方式，以广为接受的开放标准为基础来支持应用之间在消息、事件和服务级别上动态的互连互通。ESB做了 标准数据&#x2F;接口 到 各个技术和系统的数据&#x2F;接口 之间的适配工作，更好的解决不同异构系统的连接问题。<br><img src="https://gitee.com/zhaowg3/images/raw/blog/202307141920712.png"></p>
<h4 id="ESB功能定位"><a href="#ESB功能定位" class="headerlink" title="ESB功能定位"></a>ESB功能定位</h4><blockquote>
<p>原文链接：<a target="_blank" rel="noopener" href="https://blog.csdn.net/terrorist2008/article/details/84765226">https://blog.csdn.net/terrorist2008/article/details/84765226</a></p>
</blockquote>
<ul>
<li>通讯协议转换：<ul>
<li>完成调用端和服务端的通讯协议转换。比如调用端只支持HTTP协议，而服务端要求使用TCP通讯。此时ESB可以在中间转换通讯协议，而使调用端不再需要面向TCP构建报文，降低调用的复杂性，同时相当于对后台服务进行了封装以支持多种的调用方式。</li>
</ul>
</li>
<li>报文格式转换：<ul>
<li>完成调用端和服务端的使用的报文格式的转换。比如服务端要求传入XML，而调用端使用JSON报文格式。此时ESB可以转化报文格式，从而使调用端采用统一简单的报文格式调用服务端，也使服务端的一个服务可以通过多种报文格式进行调用。</li>
</ul>
</li>
<li>服务组合编排：<ul>
<li>ESB可以把后台的多个服务封装为一个服务对外公开出去。调用端只调用ESB一次，就可以调用后台的多个服务，从而降低调用的复杂性。</li>
</ul>
</li>
<li>流量控制：<ul>
<li>ESB作为后台服务的前置系统，能进行请求流量限制，防止后台应用系统超出负载能力而宕机。</li>
</ul>
</li>
<li>消息路由：<ul>
<li>ESB支持根据报文内容规则路由到不同的后台服务系统。</li>
</ul>
</li>
<li>流量监控统计：<ul>
<li>ESB有一个配套的监控系统，能监控统计各个渠道的请求次数和服务端的调用次数，图形化展示多个统计指标。从而为其他系统的负载能力管理、系统优化提供决策支撑。</li>
</ul>
</li>
<li>简化多个应用之间的调用关系、通讯结构。<ul>
<li>不使用ESB的情况下，多个系统之间直接通讯，是一种典型的网状结构。应用系统多到一定程度难以维护、管理这种调用关系。采用了ESB后，各个应用系统直接面向ESB通讯即可， 调用关系简化为星形结构，方便调用关系管理。</li>
</ul>
</li>
</ul>
<h4 id="优点-2"><a href="#优点-2" class="headerlink" title="优点"></a>优点</h4><ul>
<li>由于在逻辑上和运行时都是集中的。逻辑上会有集中的高层视野，有利于可管理性，也就是便于治理。</li>
<li>针对遗留的老系统或者外部系统无法做出改变时，可以在ESB上开发适配代码，将他们集合起来。</li>
</ul>
<h4 id="缺点-2"><a href="#缺点-2" class="headerlink" title="缺点"></a>缺点</h4><ul>
<li>由于这种集中式的中心化架构设计，在流量大时，ESB很可能成为系统瓶颈，并且服务与服务之间的调用也需要通过ESB，对ESB是强依赖。</li>
<li>通常需要在ESB再做适配代码的开发服务才能完成开放，这也导致企业内部协议众多，不利于维护。</li>
</ul>
<h3 id="分布式服务化"><a href="#分布式服务化" class="headerlink" title="分布式服务化"></a>分布式服务化</h3><h4 id="适用场景-1"><a href="#适用场景-1" class="headerlink" title="适用场景"></a>适用场景</h4><p>互联网企业，业务与技术发展快，数据基数和增量都大，并发访问高，上面那种ESB的集中式管理很容易成为瓶颈，所以需要去中心化。<br>ESB主要提供了如下功能：通讯协议转换&#x2F;报文格式转换，服务编排，消息路由，监控等，而在当下互联网企业中，大部分都是同构系统，通讯协议和报文格式比较统一，通讯协议采用restful或者rpc协议完成调用，报文格式使用JSON格式，所以不需要ESB的转换功能；针对服务编排，这部分功能可以放到对应应用中自行实现封装和对外暴露接口；这样看下来，剩下的核心功能就是：消息路由和监控。<br>在去中心化架构思想下，服务之间调用不再都必须通过ESB来完成，而是希望服务与服务之间点一点直接调用，但是这种情况下还是需要解决服务之间的注册发现和监控，例如：服务1应用部署在3台机器上，服务2调用的时候如何发现服务1应用的地址？当服务1新扩展了一台机器的时候，服务2如何知道？当服务1机器故障下线的时候，服务2如何剔除该机器？如何监控？基于此出现了第三方的中间件，服务注册发现中心，用来处理服务的注册和发现，例如：zookeeper，nacos等。<br><img src="https://gitee.com/zhaowg3/images/raw/blog/202307141920198.png"></p>
<p>所以引入服务注册发现中心之后的架构如下：<br><img src="https://gitee.com/zhaowg3/images/raw/blog/202307141921850.png"></p>
<h4 id="优点-3"><a href="#优点-3" class="headerlink" title="优点"></a>优点</h4><ul>
<li>服务之间直接调用，没有中心化的ESB层，性能上有所提升。</li>
</ul>
<h4 id="缺点-3"><a href="#缺点-3" class="headerlink" title="缺点"></a>缺点</h4><ul>
<li>调用关系又变成了网状，对监控和管理来说比较困难；</li>
<li>服务调用关系依然是有依赖性的，如果服务出现问题，可能导致各个系统不可用。</li>
</ul>
<h2 id="微服务架构"><a href="#微服务架构" class="headerlink" title="微服务架构"></a>微服务架构</h2><h3 id="什么是微服务？"><a href="#什么是微服务？" class="headerlink" title="什么是微服务？"></a>什么是微服务？</h3><p>微服务架构是 SOA 思想的一种提炼，它强调的重点之一就是业务系统彻底的组件化和服务化，通过有效的拆分应用，实现敏捷开发和部署。相比较SOA的服务化，微服务拆分的粒度更细，也更加独立。<br>例如企业现在有物流系统，电商系统，店铺系统，财务系统，秒杀系统等，SOA的服务化是将各系统的功能服务化，例如物流提供下单服务，电商系统购物服务，但是在各个服务内部还是有重复功能，例如用户，订单，支付，日志等，微服务则是将这些重复功能再次拆分，分为用户服务，订单服务，支付服务等供所有系统使用。<br><img src="https://gitee.com/zhaowg3/images/raw/blog/202307141926255.png"><br>微服务的理论基础是康威法则，康威法则的真正含义就在于，在项目达到一定规模后，团队规模和单个项目复杂度之间产生矛盾，生产力低下。多个团队维护同一个项目，在集成时往往需要各个团队的相互配合，而如果将一个项目拆分成多个小项目后，每个团队只负责该一个小项目，就能避免许多不必要的麻烦。所以说架构师不仅仅是要关心技术架构还要关心组织架构。微服务重在独立布署和独立业务，但并不是越小越好，而是通过团队规模和业务复杂度由粗到细的划分过程，所遵循的原则是松耦合和高内聚。正如 Neflix 前总监：微服务架构本质上是组织架构的重组。</p>
<h3 id="微服务与SOA区别"><a href="#微服务与SOA区别" class="headerlink" title="微服务与SOA区别"></a>微服务与SOA区别</h3><table>
<thead>
<tr>
<th><strong>功能</strong></th>
<th><strong>SOA</strong></th>
<th><strong>微服务</strong></th>
</tr>
</thead>
<tbody><tr>
<td>服务粒度</td>
<td>粗，大块业务逻辑</td>
<td>细，单独任务或小块业务逻辑</td>
</tr>
<tr>
<td>耦合度</td>
<td>通常松耦合</td>
<td>总是松耦合</td>
</tr>
<tr>
<td>管理</td>
<td>着重集中管理</td>
<td>着重分散管理</td>
</tr>
<tr>
<td>服务通信</td>
<td>重量级，ESB</td>
<td>轻量级，HTTP Restful</td>
</tr>
<tr>
<td>服务交付</td>
<td>慢</td>
<td>快</td>
</tr>
<tr>
<td>应用场景</td>
<td>传统企业</td>
<td>互联网</td>
</tr>
</tbody></table>
<h3 id="微服务的特点"><a href="#微服务的特点" class="headerlink" title="微服务的特点"></a>微服务的特点</h3><ul>
<li>每个微服务有自己私有的数据库持久化业务数据，并且只能访问自己的数据库，而不能访问其它服务的数据库</li>
<li>如果一个事务中需要操作多个数据库，这种情况也不能直接访问其它微服务的数据库，只能通过对于微服务提供的接口进行操作。</li>
<li>数据的去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的技术。在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理</li>
</ul>
<h3 id="优点-4"><a href="#优点-4" class="headerlink" title="优点"></a>优点</h3><ul>
<li>服务复用，降低成本。企业内部不同的应用间都会有一些通用的东西，比如通知、授权等，将这些服务复用起来，避免重复造轮子</li>
<li>支持快速迭代。单体应用无法满足业务增长的需求，DevOps 理念就是要支持快速迭代，如果应用架构不改，是无法在 DevOps 实践中实现快速迭代的。拆分成微服务之后，针对特定服务发布，影响小，风险小，成本低。频繁发布版本，快速交付需求。</li>
<li>高可用、高弹性和高性能。解决单体应用的业务可靠性、稳定性问题，随着时间的推移越来越多的问题。</li>
</ul>
<h3 id="缺点-4"><a href="#缺点-4" class="headerlink" title="缺点"></a>缺点</h3><ul>
<li>系统维护：服务数量比单体服务更多，部署、管理的工作量很大</li>
<li>稳定性：稳定性下降，一个服务出现故障 ，可能导致整个系统挂掉，同时整个应用被分散成多个服务，定位故障点非常困难。</li>
<li>系统测试：原本单个程序的测试变为服务间调用的测试，测试变得更加复杂。微服务化之后，单一模块无法独立完成业务功能，而集成测试会在非常靠后的时候才能做，就要求需要大量引入 API 自动化测试等测试方法。</li>
<li>开发方面：项目初期，业务简单与用户量小，单体项目的开发成本最低，开发效率最高，而选择微服务架构，需要准备很多资源，开发成本较高，开发的效率也就很低。</li>
</ul>
<p>如果当前规模恰到好处，把服务迸一步拆分不仅不会降低复杂性，反而会让系统变得更复杂。所以不是所有的应用程序都适合被拆分成微服务。同时如果拆分不好，会大量引入分布式事务，处理起来会比较麻烦；<br>如果应用程序要求各个组件和服务之间紧密集成，比如需要快速处理实时数据的应用程序。在服务之间添加新链路会导致处理速度变慢。</p>
<h3 id="常见问题"><a href="#常见问题" class="headerlink" title="常见问题"></a>常见问题</h3><ul>
<li>这么多微服务，如何管理他们？（服务注册发现中心[服务注册，发现和剔除]）</li>
<li>这么多微服务，如何管理配置？（分布式配置管理）</li>
<li>每个服务都是集群部署，如何分配流量？（负载均衡）</li>
<li>这么多微服务，相互之间如何调用？（服务调用[restful,rpc]，分布式消息）</li>
<li>这么多微服务，一个服务出现故障 ，可能导致整个系统挂掉，如何处理？（熔断）</li>
<li>这么多微服务，出现故障后，如何排查？（分布式链路追踪）</li>
<li>这么多微服务，客户端如何访问？（网关）</li>
<li>这么多微服务，如何处理跨服务的事务？（分布式事务）</li>
</ul>
<p>对于上面的问题，是任何一个微服务设计者都不能绕过去的，因此大部分的微服务产品都针对每一个问题提供了相应的组件来解决它们。<br><img src="https://gitee.com/zhaowg3/images/raw/blog/202307141926518.png"></p>
<h3 id="常见概念"><a href="#常见概念" class="headerlink" title="常见概念"></a>常见概念</h3><h4 id="分布式配置中心"><a href="#分布式配置中心" class="headerlink" title="分布式配置中心"></a>分布式配置中心</h4><p>每个微服务都有一堆配置，且根据环境的不同配置也不同，例如开发环境，测试环境，预发环境，线上环境等，如果需要更改某个配置内容，则需要对所有涉及到的微服务全部重新更改，然后发布上线，每个配置项散落在各个应用中，不方便管理和监控。针对此问题，出现了分布式配置中心，将所有微服务对应的配置集中管理，并且支持动态更新，不需要重启应用。<br><img src="https://gitee.com/zhaowg3/images/raw/blog/202307141927406.png"></p>
<h4 id="服务注册发现中心"><a href="#服务注册发现中心" class="headerlink" title="服务注册发现中心"></a>服务注册发现中心</h4><p>在微服务架构下，业务被拆分成了多个微服务，每个微服务都部署在不同机器上，且部署了多个节点，在这种情况下，如果a服务所在应用需要调用另一个应用的b服务，应该如何找到b所在机器的ip和端口？b服务故障后如何通知a？b更换了部署的机器，又如何通知a？<br>为了解决上述问题，引入了服务注册发现中心。整体架构如下：<br><img src="https://gitee.com/zhaowg3/images/raw/blog/202307141927122.png"></p>
<ul>
<li>服务提供者：将自身的服务开放出来，供其他服务调用。<ul>
<li>服务注册：服务启动的时候，将自己的元数据（应用名称，ip，端口，服务名称，版本等）注册到“服务注册发现中心”，“服务注册发现中心”记录每个服务对应的元数据列表，供服务消费者调用该服务的时候获取对应的机器信息。</li>
<li>心跳上报：心跳上报主要是为了判断服务是否故障，当“服务注册发现中心”经过一定时间没有收到服务提供者的心跳上报数据时，则认为该机器故障，在维护的列表中将该机器剔除。</li>
</ul>
</li>
<li>服务消费者：服务的调用方，调用其他服务完成相应功能。<ul>
<li>订阅服务：在服务消费者启动的时候，将自己系统使用到的外部服务，通过调用服务注册中心的相关接口获取到对应服务所在的机器列表信息，缓存到本地，方便日后直接调用。</li>
<li>通知：当某个服务下线的时候，服务注册发现中心通知服务消费者，移除该服务对应的机器。</li>
</ul>
</li>
<li>服务注册发现中心：维护每个服务对应的机器列表，如果某个机器故障，则剔除对应的故障机器。</li>
</ul>
<h4 id="服务调用"><a href="#服务调用" class="headerlink" title="服务调用"></a>服务调用</h4><p>通过上面的服务注册发现中心，已经能够找到服务提供者的ip和端口了，那么如何调用呢<br>？目前主要有HTTP协议的restful接口和 TCP的rpc协议，例如dubbo。</p>
<ul>
<li><strong>REST</strong>(Representational State Transfer)：这是一种HTTP调用的格式，更标准，更通用，无论哪 种语言都支持http协议</li>
<li><strong>RPC</strong>（Remote Promote Call）：一种进程间通信方式。允许像调用本地服务一样调用远程服务。 RPC框架的主要目标就是让远程服务调用更简单、透明。RPC框架负责屏蔽底层的传输方式、序列化方式和通信细节。开发人员在使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。</li>
</ul>
<h4 id="分布式消息"><a href="#分布式消息" class="headerlink" title="分布式消息"></a>分布式消息</h4><p>上面的服务调用，主要是同步调用，而在某些场景下是可以异步调用的，强调的是最终一致即可，例如：用户购物成功后，给用户发送短信，发放积分，下发优惠劵等，都可以异步处理，这个时候就可以使用分布式消息了。<br><img src="https://gitee.com/zhaowg3/images/raw/blog/202307141928231.png"><br>使用分布式消息有如下好处：</p>
<ul>
<li>系统解耦。</li>
<li>异步通信。</li>
<li>流量削峰。</li>
</ul>
<h4 id="负载均衡"><a href="#负载均衡" class="headerlink" title="负载均衡"></a>负载均衡</h4><p>每个微服务都是多节点部署，在正式调用的时候，如何合理分配流量，避免流量倾斜呢，这就是负载均衡要做的事情。<br><img src="https://gitee.com/zhaowg3/images/raw/blog/202307141928961.png"><br>负载均衡常见策略：随机，轮询，加权轮询，最小活跃度轮询，一致性hash，最短响应负载均衡</p>
<h4 id="服务熔断-服务降级"><a href="#服务熔断-服务降级" class="headerlink" title="服务熔断&#x2F;服务降级"></a>服务熔断&#x2F;服务降级</h4><p>在微服务当中，一个请求经常会涉及到调用几个服务，如果其中某个服务不可用，没有做服务熔断的话，极有可能会造成一连串的服务不可用，这就是雪崩效应。</p>
<ul>
<li>服务熔断</li>
</ul>
<p>  一般是某个服务故障或者是异常引起的，类似于“保险丝”，当某个异常条件被触发，为了防止服务雪崩，直接熔断服务，而不是一直等到此服务超时。<br>  典型的熔断场景：例如过载保护，当请求线程数过多时被限流，</p>
<ul>
<li>服务降级</li>
</ul>
<p>  当服务器压力剧增时，根据当前业务情况及流量，对一些非核心服务进行有策略的停服，缓解服务器资源压力，以保证核心业务的正常运行。</p>
<ul>
<li>自动降级：超时、失败次数过多、故障<ul>
<li>响应时间超过配置的超时时间（异步机制探测回复情况）</li>
<li>不稳的API调用次数达到一定数量（异步机制探测回复情况）</li>
<li>调用的服务出现故障（HTTP状态码、网络故障、RPC服务异常）</li>
</ul>
</li>
<li>人工降级：秒杀、双十一大促，非核心服务停服</li>
<li>熔断和降级异同<ul>
<li>相同点<ul>
<li>从可用性和可靠性触发，为了防止系统崩溃</li>
<li>最终让用户体验到的是某些功能暂时不能用</li>
</ul>
</li>
<li>不同点<ul>
<li>服务熔断一般是下游服务故障导致的</li>
<li>服务降级一般是从整体系统负荷考虑，由调用方控制</li>
</ul>
</li>
</ul>
</li>
</ul>
<h4 id="分布式链路追踪"><a href="#分布式链路追踪" class="headerlink" title="分布式链路追踪"></a>分布式链路追踪</h4><blockquote>
<p>参考：<a target="_blank" rel="noopener" href="https://baijiahao.baidu.com/s?id=1708807913437543359&wfr=spider&for=pc">https://baijiahao.baidu.com/s?id=1708807913437543359&wfr=spider&for=pc</a></p>
</blockquote>
<p>在微服务架构下，一次请求往往需要涉及到多个服务，而这些不同的服务可能由不同团队开发，使用不同的语言，部署在几千台服务器上等等，如果发生故障，应该如何排查呢？如何定位该请求对应的整个调用链呢？这就是分布式链路要解决的问题。<br>主要功能：</p>
<ul>
<li>故障快速定位：可以通过调用链结合业务日志快速定位错误信息。</li>
<li>链路性能可视化：各个阶段链路耗时、服务依赖关系可以通过可视化界面展现出来。</li>
<li>链路分析：通过分析链路耗时、服务依赖关系可以得到用户的行为路径，汇总分析应用在很多业务场景。</li>
</ul>
<p>实现原理</p>
<ul>
<li><p>Trace：Trace的含义比较直观，就是链路，指一个请求经过所有服务的路径，可以用下面树状的图形表示。<br><img src="https://gitee.com/zhaowg3/images/raw/blog/202307141929615.png"><br>图中一条完整的链路是：chrome -&gt; 服务A -&gt; 服务B -&gt; 服务C -&gt; 服务D -&gt; 服务E -&gt; 服务C -&gt; 服务A -&gt; chrome。服务间经过的局部链路构成了一条完整的链路，其中每一条局部链路都用一个全局唯一的traceid来标识。</p>
</li>
<li><p>Span</p>
</li>
</ul>
<p>在上图中可以看出来请求经过了服务A，同时服务A又调用了服务B和服务C，但是先调的服务B还是服务C呢？从图中很难看出来，只有通过查看源码才知道顺序。<br>为了表达这种父子关系引入了Span的概念。<br>同一层级parent id相同，span id不同，span id从小到大表示请求的顺序，从下图中可以很明显看出服务A是先调了服务B然后再调用了C。<br>上下层级代表调用关系，如下图服务C的span id为2，服务D的parent id为2，这就表示服务C和服务D形成了父子关系，很明显是服务C调用了服务D。<br><img src="https://gitee.com/zhaowg3/images/raw/blog/202307141929188.png"><br>总结：通过事先在日志中埋点，找出相同traceId的日志，再加上parent id和span id就可以将一条完整的请求调用链串联起来。</p>
<h4 id="网关路由"><a href="#网关路由" class="headerlink" title="网关路由"></a>网关路由</h4><p>随着微服务的不断增多，不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求，如果让客户端直接与各个微服务通信可能出现：</p>
<ul>
<li>客户端需要调用不同的url地址，增加难度</li>
<li>在一定的场景下，存在跨域请求的问题</li>
<li>每个微服务都需要进行单独的身份认证</li>
</ul>
<p>针对这些问题，API网关顺势而生。<br>API网关直面意思是将所有API调用统一接入到API网关层，由网关层统一接入和输出。一个网关的基本功能有：统一接入、安全防护、流量管控、服务熔断能力。有了网关之后，各个API服务提供团队可以专注于自己的的业务逻辑处理，而API网关更专注于安全、流量、路由等问题。<br><img src="https://gitee.com/zhaowg3/images/raw/blog/202307141930973.png"></p>
<h3 id="微服务架构的常见解决方案"><a href="#微服务架构的常见解决方案" class="headerlink" title="微服务架构的常见解决方案"></a>微服务架构的常见解决方案</h3><p>Spring Cloud 和 Spring Cloud Alibaba。<br>相关内容见后续文章。</p>
<h2 id="服务网格"><a href="#服务网格" class="headerlink" title="服务网格"></a>服务网格</h2><blockquote>
<p>原文链接：<a target="_blank" rel="noopener" href="https://blog.csdn.net/weixin_43637013/article/details/123965365">https://blog.csdn.net/weixin_43637013&#x2F;article&#x2F;details&#x2F;123965365</a></p>
</blockquote>
<h3 id="什么是服务网格？"><a href="#什么是服务网格？" class="headerlink" title="什么是服务网格？"></a>什么是服务网格？</h3><p>上面的微服务架构，将系统拆分成了多个服务，为了治理这些服务，引入了众多的中间件，单独看一个微服务，其实可以分为2类：</p>
<ul>
<li>功能性需求：自身的业务逻辑</li>
<li>非功能性需求：例如负载均衡，路由，超时重试，熔断，安全监控，流量控制，认证等。</li>
</ul>
<p>每个微服务中都包含了和业务逻辑无关的非功能性需求，如果将这部分需求单独拆分出来，开发人员只专注于业务逻辑实现即可。<br><img src="https://gitee.com/zhaowg3/images/raw/blog/202307141930487.png"><br>将这种专注于非功能性需求的组件，起了一个名字叫做边车（sidecar）服务。为啥叫这个呢？请看下面这种图：<br><img src="https://gitee.com/zhaowg3/images/raw/blog/202307141931866.png"><br>有了sidecar之后，微服务之间的调用则变成了如下形式：<br><img src="https://gitee.com/zhaowg3/images/raw/blog/202307141931326.png"><br>这种图片描述了服务间的依赖形态，就像一张服务组成的网：service（服务）-mesh（网格），所以叫服务网格。<br>维基百科的解释：</p>
<blockquote>
<p>在软件架构中，服务网格是一个专用的基础设施层，用于使用代理促进服务或微服务之间的服务到服务通信。专用通信层可以提供许多好处，例如提供对通信的可观察性，提供安全连接，或自动重试和回退失败的请求。<br>服务网格由与应用程序中的每个服务配对的网络代理和一组任务管理流程组成。代理称为数据平面，管理进程称为控制平面。数据平面拦截不同服务之间的调用并“处理”它们；控制平面是网格的大脑，负责协调代理的行为，并为运维人员提供 API 来操作和观察整个网络<br><img src="https://gitee.com/zhaowg3/images/raw/blog/202307141931093.png"><br>如果没有服务网格，每个微服务都会自行实现业务逻辑和横切关注点 (CCC)。<br>使用服务网格，许多 CCC（如流量指标、路由和加密）被移出微服务并进入代理。业务逻辑和业务指标保留在微服务中。传入和传出请求通过代理透明地路由。除了一层代理（数据平面）之外，服务网格还添加了一个所谓的控制平面。它将配置更新分发给所有代理，并接收代理收集的指标以进行进一步处理，例如由 Prometheus 等监控基础设施。</p>
</blockquote>
<h3 id="服务网格的特点"><a href="#服务网格的特点" class="headerlink" title="服务网格的特点"></a>服务网格的特点</h3><ul>
<li>非侵入式代理：服务网格引入的sidecar作为业务微服务的代理，承担了非业务功能：如流量管理、安全认证、监控运维等。sidecar卸载掉了业务微服务的通用功能，使得业务开发人员专注于业务逻辑开发，无需关注其他非业务需求。</li>
<li>非业务公共能力解耦：业务微服务功能与sidecar非业务功能分离解耦，业务微服务专注于业务逻辑，与业务逻辑无关的DFX特性，如流量管理、安全认证、监控运维等，全部旁路到sidecar容器统一处理；</li>
<li>管理面数据面分离：这也是服务网格的一大优势，通过将控制面与数据面分离解耦，达到不同问题域的解耦目标。控制面只聚焦安全、监控、流量等策略的处理和下发，数据面只聚焦如何执行策略，各自的故障不会相互影响，例如控制面的故障不会影响数据面的流量转发。后面会进一步介绍控制面数据面分离的架构。</li>
</ul>
<h3 id="服务网格的适用场景？"><a href="#服务网格的适用场景？" class="headerlink" title="服务网格的适用场景？"></a>服务网格的适用场景？</h3><p>软件世界没有银弹，任何好的技术是把双刃剑，service-mesh也要结合具体场景、具体问题来看落地的可能性。<br>服务网格的设计初衷，就是为了解决业务服务的非业务功能部分复杂度。只要业务服务发展到一定规模，遇到了诸如分布式微服务内&#x2F;外的流量调度问题、安全隔离和认证以及监控指标采集和全局调用链分析等，都可以复用服务网格的现有能力。<br>当然，服务网格的引入本身会带来额外的成本：包括资源投入成本、运维投入成本、业务服务改造成本，需要结合业务线的具体情况进一步评估：</p>
<ul>
<li>资源投入成本：第一是网格控制面组件的引入（以istio为例，包括istiod,Prometeus,jagger），带来的部署资源消耗；第二是数据面的每个业务微服务都需要注入sidecar，带来的部署资源消耗和流量进出多一跳的性能消耗。尤其是数据面的性能消耗，对于某些性能敏感的微服务需要仔细评估。当然，也可以通过水平扩容的方式来解决。</li>
<li>运维投入成本：服务网格为业务服务提供了便捷的运维监控能力，但其自身引入的运维复杂度非常高，例如服务网格中最流行的istio，引入了VirtualService、DestinationRule、ServiceEntry等模型，动辄上百行的流量规则配置，在现网运维上需要非常大的投入。同时，端到端的追踪流量策略在哪些微服务上生成、下发、生效，目前也没有成熟的工具。</li>
<li>业务服务改造成本：服务网格体系一般是建立在云原生的体系架构上，即部署在K8s之上并且使用Prometeus，jagger，Zipkin等k8s生态组件。对于没有容器化的业务微服务如部署在VM、物理服务器的服务，需要先进行容器化改造后才能享受到服务网格的全部能力。</li>
</ul>
<h2 id="分布式架构演变"><a href="#分布式架构演变" class="headerlink" title="分布式架构演变"></a>分布式架构演变</h2><p>综上所述，分布式架构也经历了如下演化：<br><img src="https://gitee.com/zhaowg3/images/raw/blog/202307141932256.png"></p>
<ul>
<li>面向服务架构(Service Oriented Architecture，SOA)：<ul>
<li>以业务服务的角度和服务总线的方式 （一般是WebService与ESB）考虑系统架构和企业IT治理；</li>
</ul>
</li>
<li>分布式服务架构（Distributed Service Architecture，DSA)：<ul>
<li>基于去中心化的分布式服务框架与技术，考虑系统架构和服务治理；</li>
</ul>
</li>
<li>微服务架构（MicroServices Architecture，MSA)：<ul>
<li>微服务架构可以看做是面向服务架构和分布式服务架构的拓展，使用更细粒度的服务和一组设计准则来考虑大规模的复杂系统架构设计。</li>
</ul>
</li>
<li>服务网格架构（Service Mesh Architecture，SMA）:<ul>
<li>服务网格主要是将微服务架构中与业务无关的非功能性需求，如网络通信，安全，监控，流量控制等，解耦到单独的服务sidecar进行处理，代理微服务之间的服务通信，多个sidecar之间的连接和交互组成了网格(mesh)。</li>
</ul>
</li>
</ul>
<h1 id="参考资料"><a href="#参考资料" class="headerlink" title="参考资料"></a>参考资料</h1><p><a target="_blank" rel="noopener" href="https://blog.csdn.net/asdf12388999/article/details/128837729">架构师之路—架构的演变详解</a><br><a target="_blank" rel="noopener" href="https://m.163.com/dy/article/DC33E2AG0511FQO9.html">如何向小白讲述软件架构发展历程</a><br><a target="_blank" rel="noopener" href="https://blog.csdn.net/terrorist2008/article/details/84765226">ESB 的功能定位</a><br><a target="_blank" rel="noopener" href="https://blog.csdn.net/weixin_43637013/article/details/123965365">什么是服务网格service-mesh？</a><br><a target="_blank" rel="noopener" href="https://blog.csdn.net/u012102104/article/details/105404620/">服务熔断降级简介</a><br><a target="_blank" rel="noopener" href="https://baijiahao.baidu.com/s?id=1708807913437543359&wfr=spider&for=pc">三分钟带你搞懂分布式链路追踪系统原理</a></p>

    </div>

    
    
    

    <footer class="post-footer">
          <div class="post-tags">
              <a href="/tags/Spring/" rel="tag"># Spring</a>
              <a href="/tags/Spring-Cloud/" rel="tag"># Spring Cloud</a>
          </div>

        

          <div class="post-nav">
            <div class="post-nav-item">
                <a href="/2019/05/23/Hexo-NexT-%E7%A0%81%E4%BA%91%E6%90%AD%E5%BB%BA%E4%B8%AA%E4%BA%BA%E5%8D%9A%E5%AE%A2/" rel="prev" title="Hexo+NexT+码云搭建个人博客">
                  <i class="fa fa-chevron-left"></i> Hexo+NexT+码云搭建个人博客
                </a>
            </div>
            <div class="post-nav-item">
                <a href="/2023/07/14/%E6%9C%89%E8%B6%A3%E7%9A%84%E5%B0%8F%E5%B7%A5%E5%85%B7/" rel="next" title="有趣的小工具">
                  有趣的小工具 <i class="fa fa-chevron-right"></i>
                </a>
            </div>
          </div>
    </footer>
  </article>
</div>






</div>
  </main>

  <footer class="footer">
    <div class="footer-inner">

  <div class="copyright">
    &copy; 
    <span itemprop="copyrightYear">2023</span>
    <span class="with-love">
      <i class="fa fa-heart"></i>
    </span>
    <span class="author" itemprop="copyrightHolder">zhaowg</span>
  </div>
  <div class="powered-by">由 <a href="https://hexo.io/" rel="noopener" target="_blank">Hexo</a> & <a href="https://theme-next.js.org/" rel="noopener" target="_blank">NexT.Gemini</a> 强力驱动
  </div>

    </div>
  </footer>

  

<noscript>
  <div class="noscript-warning">Theme NexT works best with JavaScript enabled</div>
</noscript>


  
  <script src="https://cdnjs.cloudflare.com/ajax/libs/animejs/3.2.1/anime.min.js" integrity="sha256-XL2inqUJaslATFnHdJOi9GfQ60on8Wx1C2H8DYiN1xY=" crossorigin="anonymous"></script>
<script src="/js/comments.js"></script><script src="/js/utils.js"></script><script src="/js/motion.js"></script><script src="/js/next-boot.js"></script>

  




  <script src="/js/third-party/pace.js"></script>


  





</body>
</html>
